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Abstract 


Data  sharing  is  a  difficult  problem  with  a  variety  of  issues.  There  is  a  need  to  share  data 
across  multiple  enterprises,  diffo-ent  hardware  platforms,  different  data  storage  para¬ 
digms,  and  a  variety  of  network  architectures,  nre  ISO  Standard  for  the  Exchange  of 
Product  Model  Data  (STEP)  addresses  this  need  by  providing  information  models 
which  clearly  and  unambiguously  describe  data.  The  validity  of  these  information 
models  is  essential  for  success  in  sharing  data  in  a  highly  automated  business  environ¬ 
ment. 

The  design  of  software,  which  supports  the  testing  of  information  models  for  validity 
and  correcmess,  is  described  in  this  document.  This  design  follows  requirements  and  an 
architecture  described  in  previously  published  Validation  Testing  System  (VTS)  project 
documents.  The  collection  of  these  documents  provides  a  basis  for  software  develop¬ 
ment  within  the  National  PDES  Testbed.  The  Testbed  is  used  to  validate  information 
models  for  STEP.  The  scope  of  this  document  is  limited  to  the  design  of  those  compo¬ 
nents  of  VTS  software  scheduled  for  development  in  the  initial  phasp  of  the  project 


1  Introduction 


The  software  described  in  this  document  supports  the  Validation  Testing  System  (VTS) 
at  the  National  PDES  Testbed*.  The  Testbed  is  used  by  researchers  to  test  the  validity  of 
application  protocols,  or  application  models^,  whidi  are  being  proposed  for  STEP^. 


1.  Funding  for  this  work  and  the  Testbed,  located  at  NIST,  has  been  provided  by  the  Department 
of  Defense’s  Computer-Aided  Acquisition  and  Logistic  Support  (CALS)  Office.  PDES,  Product 
Data  Exchange  using  STEP,  is  the  U.S.  activity  in  support  of  the  international  STEP  standard. 

2.  The  term  application  model  will  he  used  throughout  this  paper  to  refer  to  the  domain  specific 
schema  which  is  being  evaluated  whether  that  be  an  application  protocol  ( AP),  an  application 
resource  model  (ARM),  a  context  driven  integrated  model  (CDIM),  or  some  other  form  of  an 
application  schema. 

3.  The  Standard  for  the  Exchange  of  Product  Model  Data  (STEP)  is  a  project  of  the  International 
Organization  for  Standardization  aSO)  Technical  Committee  on  Industrial  Automation  Systems 
(TC 184)  Subcommittee  on  Manufacturing  Data  and  Languages  (SC4). 
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TTie  testing  process  is  described  in  a  paper  outlining  the  methodology  for  Application 
Protocol  validation  [Mitch91]. 

The  design  architecture  [MoiTis92]  provides  a  framework  for  the  software  developed 
within  the  VTS  project.  The  software  described  in  this  document  will  be  designed  and 
implemented  incrementally  as  resources  are  available.  Likewise,  this  document  will  be 
updated  regularly  as  the  design  of  the  various  software  components  is  completed.  For  a 
complete  description  of  the  VTS  document  series  please  see  Appendix  B'*. 

The  initial  emphasis  of  the  VTS  software  is  the  support  of  Test  Data  Generation  soft¬ 
ware,  more  commonly  known  as  the  Data  Probe.  Therefore,  the  software  components 
detailed  in  this  document  directly  suppwt  the  requirements  for  Test  Data  Generation. 

The  audience  for  this  document  includes  software  designers  and  developers.  This  docu¬ 
ment  builds  (HI  (he  software  architecture  covered  in  the  VTS  architecture  document 
^orris92].  This  jqrproach  is  relevant  to  those  software  developm  concerned  with  the 
development  of  STEP-based  schema  driven  software  for  production  oriented  environ¬ 
ments. 

A  Note  on  Document  Style 

Ihroughout  this  docximent  we  have  used  a  number  of  typographic  practices  to  improve 
clarity,  as  indicated  in  FIGURE  1 .  All  referen<%s  to  the  names  of  software  modules,  and 
libr^es  are  in  italics,  classes  and  specific  fiagments  of  code  (EXPRESS,  C  or  C4+)  are 
set  in  courier.  The  actual  names  of  attributes  and  functions  in  these  diagrams  do  not 
necessarily  ccrrespond  to  existing  ctxle.  This  is  not  a  software  refoence  manual,  and 
names  are  meant  to  be  descriptive  in  nature. 

Class  diagrams  are  drawn  with  the  following  OMivention: 


FIGURE  1 


Class  illustration  conventions 


ClassName 

Attributel  _ 

AttributeLisi 

Functionl 

Function2 

pointers  to 
other  objects  are 
illustrated  with 
arrows 


-indicates  a  list 
of  items 


typeset  in  courier  regular 
■typeset  in  courier  oblique 


4.  No  ^proval  or  «idorsement  of  any  product  by  (he  National  Institute  of  Standards  and  Tech¬ 
nology  IS  intended  or  implied.  The  work  described  is  funded  by  the  United  States  Government 
and  is  not  subject  to  copyright. 
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2  Overview 


The  VTS  software  architecture  integrates  modular  software  libraries.  TTiese  libraries 
will  be  incorporated  into  a  single  system  which  supports  functions  needed  for  the  vali¬ 
dation  process  [Mitch91].  Ibe  use  of  object-oriented  techniques  and  standard  interfaces 
will  enable  software  reusability.  The  systan  will  use  software  as  available  ftom  external 
sources.  When  such  software  is  unavailable,  the  necessary  software  will  be  developed. 
Support  for  flie  implementation  methods  specific  to  STEP  will  need  to  be  developed. 

Sinw  STEP  is  a  developing  standard,  the  mechanisms  for  its  implementation  are  not 
stabilized.  Furthermore,  since  these  mechanisms  are  developing  concurrently  with  the 
application  models  which  the  VTS  software  is  used  to  validate,  it  is  unlikely  that  exter¬ 
nally  developed  software  will  be  available  in  the  necessary  time  ftame.  These  mecha¬ 
nisms  include  the  specification  language  for  the  rqrplication  models  -  EXPRESS 
[ISOll]  ~  and  the  data  interface  formats,  such  as  the  exchange  file  format  [IS021].  The 
VTS  must  be  responsive  to  changes  in  these  implementation  mechanisms  by  providing 
software  which  is  quickly  and  easily  adjqrtable  to  new  versions  of  the  mechanisms. 

The  foUowing  goals  have  influenced  the  design  of  the  VTS  software  architecture: 

■  minimize  the  impact  of  changes  to  the  standard  on  implementation  software 

■  pmnit  easy  transition  of  the  software  to  support  a  new  ^Ucation  model, 

■  minimize  the  need  for  data  translation  by  providing  an  integrated  system  which  sup¬ 
ports  a  broad  range  of  functions, 

■  provide  a  single  end-user  program, 

■  enable  the  development  of  different  style  user  interfaces, 

■  allow  for  the  integration  of  externally  developed  software  into  the  system,  and 

■  develop  reusable  software. 

All  the  software  components  needed  to  support  the  testing  process  involve  the  comput¬ 
erized  manipulation  of  data  based  on  a  common  schema  or  application  model.  There¬ 
fore,  the  approach  taken  has  been  to  develop  a  library  of  data  structures  and  access 
functions  for  rqrresenting  a  schema  which  can  be  shared  among  the  different  compo¬ 
nents.  These  data  structures  must  be  rich  enough  to  store  data  and  provide  some 
sonantic  information  ftom  the  applicaticm  models  at  runtime.  Semantic  information 
needed  at  runtime  includes  the  names  of  the  structures,  their  fields,  and,  when  possible, 
acceptable  values  for  the  fields  and  rules  governing  instance  structure.  In  the  initial 
implanentation  the  latter  information  is  available  only  by  displaying  the  application 
model,  as  specified  in  EXPRESS,  to  the  user. 

Relationships  between  the  VTS  Software  Components 

This  section  discusses  relationships  between  the  VTS  software  layers  as  specified  in  the 
VTS  architecture  document  [MorTis92].  The  application  model  specific  libraries,  the 
VTS  specific  libraries,  and  the  generic  systems  each  contain  functional  ftlfttnftnfs  of  this 
software.  The  VTS  software  design  is  confined  irtitially  to  the  componrats  in  these 
layers.  Only  tire  first  2  layers  are  discussed  here,  since  software  in  the  “generic”  layer  is 
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FIGURE  2 


expected  to  come  from  outside  (i.e.  commercial  or  public  domain)  sources.  Dependen¬ 
cies  between  the  software  in  these  layers  are  shown  in  FIGURE  2. 


VTS  Software  Component  Relationships 


LEGEND: 


Indicates  Dependency 
Generated  Library 


the  divisirai  of  the  V  IS  software  into  component  libraries  enables  code  reuse  by  enc^ 
sulating  the  funcfronality  needed  for  different  aqiects  of  the  validation  process.  Several 
considerations  are  influential  in  defining  the  components  of  the  VTS  software,  but  two 
functional  requirements  are  of  particular  importance: 


VTS  Specific  /  Model  independent  Layer 


■  the  need  to  easily  transition  the  software  to  a  new  application  model,  and 

■  the  desire  to  enable  different  user  interfaces  to  be  developed. 

The  conceptual  division  of  VTS  software  is  based  on  these  requirements.  The  informa¬ 
tion  from  a  particular  application  model  is  encapsulated  in  the  Schema  Class  Library. 
The  Data  Editor  Library  encapsulates  the  information  and  operations  needed  for  manip¬ 
ulating  and  editing  that  information.  The  VTS  Interface  Library  ccmtains  the  operations 
needed  to  present  that  information  to  the  user.  The  presentation  format  in  the  user  inter¬ 
face  is  not  influenced  by  the  specific  content  of  the  information  but  uses  generalizations, 
or  abstractions,  about  the  structure  of  the  information.  These  abstractions  are  based  on 
EXPRESS  and  are  supported  by  the  STEP  Class  Library. 

The  VTS  architecture  layering  supports  modularization  of  the  software.  Component 
libraries  in  each  layer  are  dependent  on  some  of  the  libraries  in  the  nexL  more  genoal 
layer.  However,  the  more  general  layers  are  not  dependent  on  the  less  general  layers. 

For  example,  the  VTS  specific  layer  dqwnds  on  the  generic  systems  layer,  but  not  vice 
versa.  Dependencies  are  limited  to  the  interface  between  layers.  The  exception  is  in  the 
database  management  system.  The  database  system  will  come  from  an  external  source 
and  will  have  its  own  particular  structure. 

The  VTS  architecture  is  structured  to  enable  reuse  of  the  software.  A  different  style  of 
user  interface  could  be  developed  for  the  VTS  software  by  replacing  the  VTS  Interface 
Library.  This  can  be  done  without  affecting  the  data  editing  and  representation  capabUi- 
tiw  of  the  system.  For  example,  two  different  systems  could  be  developed  by  replacing 
this  library.  One  could  support  window-based  intafaces  and  the  other  ASCII-based 
interfaces.  These  systems  would  provide  the  same  functions  in  terms  of  editing  and 
representational  capabilities,  since  those  components  of  the  software  would  not  change. 

Other  programs  may  use  parts  of  the  VTS  software.  In  particular,  the  STEP  Class 
Library  and  Schema  Class  libraries  may  represent  the  application  data  structures.  Stand¬ 
alone  translators  could  be  developed  using  these  libraries.  These  translators  would  not 
be  dependent  on  the  VTS  Interface  Library  which  may  require  a  sophisticated 
windowing  system.  But  they  would  share  the  same  data  representation  rapahiiities  of 
the  VTS  software  and  would  be  able  to  directly  access  the  same  database  using  the 
interface  provided  in  the  Schema  Class  Library.  The  interface  to  the  database  would  be 
transparent  to  the  translators.  Likewise,  parts  of  the  VTS  Interface  and  Data  Editor 
libraries  could  be  used  for  any  general  purpose  editor  of  highly  structured  information. 


3  VTS  Specific  /  Model  Independent  Layer 


Software  in  this  layer  is  specific  to  the  needs  of  validation  testing  but  independent  of 
any  particular  application  model.  These  include  the  data  structures  needed  to  represent 
entities.  In  addition,  the  functionality  for  editing  the  data  contained  in  these  data  struc¬ 
tures  is  in  this  layer. 

3.1  STEP  Class  Library 

Die  STEP  Class  Library  (SCL)  is  a  collection  of  plication  independent  class  defini¬ 
tions.  They  are  used  by  the  plication  dependoit  classes  found  in  flie  Schema  Class 
Library.  Classes  found  in  the  SCL  include  a  common  **base”  class  for  all  entity  class 
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definitimis  and  classes  to  maintain  meta-infonnation  firran  the  schemas.  After  a  brief 
description  of  some  problems  solved  by  the  SCL,  this  section  will  conclude  with  defini¬ 
tions  of  the  major  classes  in  this  library. 

The  STEP  Class  Library  (see  FIGURE  3)  provides  functionality  for  supporting  a 
Schema  Class  Library,  a  dicticmary  of  the  application  model,  and  data  files.  The  SCL  is 
dependent  on  the  external  C++- libraries  for  standard  input  and  output  [McLay90]. 

The  problem  with  any  translation  of  a  conceptual  model  into  an  implementation 
language  is  the  translation  of  the  semantics  conveyed  by  the  conceptual  model.  The 
symbolic  names  used  in  a  model  store  some  of  the  meaning  intended  by  the  modelers. 
Consider  the  following  type  definition; 

TYPE  inches  =  INTEGER; 

END_TYPE; 

To  a  human  reading  a  concq»tual  model,  the  term  inches  conveys  more  information  than 
the  term  integer.  At  first  glance,  it  may  seem  as  if  inches  can  simply  be  translated  to  an 
integer  and  all  would  be  well;  however,  this  approach  does  not  maintain  the  semantics 
captured  by  the  term  inches.  Inches  is  a  specific  unit  of  measurement  not  simply  a 
number. 

To  capture  the  symbolic  information  several  classes  have  been  created.  The  STEPentity 
class  captures  infonnation  pertaining  to  the  entities  of  the  concq>tual  model;  the 
STEPattribute  class  handles  the  descriptions  of  the  entity’s  attributes. 


FIGURE  3  STEP  Class  Library  -  major  classes  and  relationships 


3.1.1  Class  Relationships  within  STEP  Class  Library 

The  STEPentity  class  cwitains  the  functions  STEPread  and  STEPwrite  which 
encapsulate  the  behavior  required  to  read  and  write  an  entity  encoded  in  the  STEP 
exchange  file  format. 
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The  STEPattr  ibuteList  is  a  list  of  pointers  to  the  instances  of  the  attributes  of  an 
entity.  Functions  can  traverse  the  list  of  attributes  without  any  knowledge  of  attribute 
types.  Information  in  the5TEPattribute  class  describes  the  type  of  an  attribute  for 
a  given  instance  of  the  attribute.  Using  this  infcxmation  the  STEPattr  ibute  can 
“validate”  itself  by  ensuring  that  the  data  pointed  to  by  the  STEPattr  ibute  corre- 
sptmds  to  the  conect  type. 

The  descriptive  information  from  a  schema  is  enc^sulated  in  a  set  of  classes,  which 
populates  a  Registry  (see  FIGURE  4).  The  Registry  is  used  as  adictionary 
to  the  contents  of  the  schema  for  the  application  model.  The  Registry  is  also  used  to 
create  new  instances  of  the  STEPent  i  ty  class  at  run-time  based  on  the  entity’s 
symbolic  name. 

The  objects  contained  in  the  Registry  are  instances  of  Entity  Descriptors 
and  Attribute  Descriptors.  These  classes  maintain  information  about  an  entity 
such  as  its  name,  the  supertype(s)  and  subtypes,  and  the  names  of  its  attributes.  The 
information  in  the  Registry  mirrors  the  particular  schema  being  used. 


FIGURE  4 


Registry  classes 


EntltyDescriptor 

Name 

SuperTypes 

m— 

SubTypes 

— 

AttributeDescriptors 

••• 

.4 


AttributeDescriptor 


TypeDescriptor 


3.1 .2  Relationships  to  other  Libraries 

The  STEPent  ity  class  is  the  link  to  the  other  libraries  within  the  VTS  software.  The 
VTS  Interface  Library  provides  the  interactive  user’s  view  of  an  instanrp.  of  an  entity. 
The  view  is  dependent  on  the  STEPent  i  ty  class  to  provide  its  structure. 

Classes  in  the  Para  Editor  Library  manage  sets  of  instances  of  the  STEPentity  class. 
The  Data  Editor  Library  is  unaware  of  the  contents  of  the  instances  but  is  able  to  gener- 
ically  manipulate  them.  Likewise,  the  STEPf  i  le  class  is  able  to  generically  operate  on 
instances  of  the  STEPent  i  ty  class,  leaving  the  details  of  the  file  syntax  to  be  handled 
by  the  STEPentity  and  STEPattribute  classes. 
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The  Registry  is  used  by  theDafa  Editor  Library.  The  Registry  provides  func¬ 
tions  for  insming,  deleting,  and  retrieving  entity  descriptors.  All  of  die  entity  descrip¬ 
tors  in  the  Registry  must  be  unique.  To  support  this  functionality  the  nodes  in  the 
Registry  have  a  key.  In  EXPRESS  a  unique  key  is  determined  by  the  combination  of 
the  entity  name  and  schema  name,  but  in  this  implementation  uniqueness  is  determined 
by  entity  name  alone.  Entity  names  may  not  be  used  in  more  than  one  schema. 

3.1.3  Classes 

The  STEP  Class  Library  consists  of  two  parallel  sets  of  classes  (see  TABLE  1 ):  one 
dealing  with  instances  and  the  other  dealing  with  symbolic  descriptions  of  the  instances, 
the  schema.  Each  set  ccmtains  a  class  for  rq>resenting  entities  and  a  class  for  repre¬ 
senting  attributes.  The  library  also  contains  parallel  sets  of  classes  whidi  are  specialized 
for  different  types  of  attributes  (i.e.  aggregate  attributes.)  These  specialized  classes  are 
not  described  in  detail  in  this  document.  (A  model  written  in  EXPRESS  describes  all  the 
classes  for  the  Registry  of  EXPRESS.  See  the  Appendix  for  details  on  this  model.) 


TABLE  1 


Primary  Classes  of  the  STEP  Class  Library 

instance 

schema 

STEPentity 

EntityDescriptor 

STEPattribute 

AttributeDescriptor 

TypeDescriptor 

STEPattributeList 

Registry 

The  separation  of  sets  of  classes  is  guided  by  fte  multiple  uses  for  the  library.  One  cate¬ 
gory  of  functions  that  the  library  is  intended  to  support  involves  interactive  browsing  of 
an  application  model;  the  other  category  of  functions  involves  translations  of  data  into  a 
particular  plication  model.  For  interactive  tools  the  symbolic  descriptions  of  the 
^plication  model  is  needed.  For  translators  a  programming  interface  to  the  application 
model  is  sufiBcient  Many  tools  (i.e.,  a  data  editor),  however,  support  combinations  of 
these  functions  and,  therefore,  use  both  sets  of  classes. 

STEPentity 

The  abstract  base  class,  STEPentity,  enables  the  generic  manipulation  of  the  specific 
classes  which  correspond  to  oitities  in  the  application  model  -  the  classes  generated  (by 
the  fedexj)lus  utility)  from  an  EXPRESS  schema.  The  STEPentity  class  encapsu¬ 
lates  the  access  to  infixmation  about  an  instance  of  entity,  including  both  values  for  its 
attributes  and  symbolic  information  describing  the  entity’s  type.  The  STEPentity 
class  does  not  maintain  this  information  directly.  Tlie  values  for  the  attributes  are  main¬ 
tained  by  the  appropriate  subclass  of  the  STEPentity.  The  symbolic  infnrmatifin  is 
provided  by  the  Entity  Descriptor.  However,  all  this  information  can  be 
accessed  through  the  STEPentity  class. 
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In  addition,  the  STEPent  i  ty  class  provides  the  necessary  functions  for  implftmpnting 
the  STEP  file  exchange  protocol  [IS021]  and  initiating  instance  validation.  In  partic¬ 
ular,  the  STEPent  ity  class  contains  an  instance  identifier,  error  state  information,  and 
a  list  of  its  attributes.  The  identifier  is  used  to  maintain  the  instances’s  identifier  for  an 
exchange  file.  The  error  state  is  used  to  report  invalid  or  missing  data  values.  As  the  ISO 
standard  develops,  the  STEPent  ity  class  may  be  used  in  the  implementation  of  other 
data  sharing  features  such  as  an  identifier  which  has  a  troader  context  than  an  exchange 
file. 

A  key  design  goal  for  the  SCL  was  to  isolate  the  implementation  of  the  exchange  proto¬ 
col  from  the  generated  class  definitions  for  a  particular  application  model.  By  doing  so, 
it  is  possible  to  change  the  exchange  protocol  without  modifying  code  that  uses  the 
Schema  Class  Library.  This  approach  also  serves  to  isolate  the  details  of  the  exchange 
protocol  frran  the  uscts  of  the  software. 

The  exchange  file  has  a  syntactic  format  based  on  an  EXPRESS  schema.  ITie  file  is  a 
series  of  sets  of  data  values.  The  format  of  the  data  sets  is  based  directly  on  the  entity 
definitions  of  the  corresponding  application  model.  The  fragment  below  shows  an 
example  of  the  file  exchange  format  The  numbers  preceded  by  the  symbol  @  are 
instance  identifiers.  Hie  following  fragment  is  from  a  STEP  exchange  file  based  on  the 
Geometry  model  [IS042]  (this  example  is  from  a  very  early  version  of  the  file  format): 

STEP; 

HEADER; 

FILE_IDENTIFICATION('IBMPRT2', '1990  01  24  18  30 
17', ('L.MCKEE' ), ('COMPANY  3' ), '1', '1', 'PDES') ; 

FILE_DESCRIPTION ( ' SIMPLE  PART' ) ; 

IMP_LEVEL('USER  DEFINED  ENTITIES  ONLY' ) ; 

ENDSEC; 

DATA; 


@19=DIRECTION(,,0.7071067845031212,0.7071067845031212,0.); 
@20=DIRECTION{, ,-0.7071067845031212,0.7071067845031212,0. ) ; 
®21=DIRECTION( , , 0 ., 0 ., 1 . 0000000308363815 ) ; 

@22=CARTESIAN_POINT (, ,0.0625,21. 3794994354248047 ,11.5299997329711 
914); 

a23=TRANSFORMATION{ , , #19,  #20 , #21 , #22 , ) ; 

@24 =COORDINATE_S YSTEM (,,,#23); 

STEPattribute 

Like  the  STEPent  ity  class  the  STEPattribute  class  enc^sulates  the  access  to 
infonnatim  about  values  for  an  entity’s  attributes  and  symbolic  information  describing 
the  attribute.  The  actual  values  for  an  entity’s  attributes  are  maintainp/i  by  the  appro¬ 
priate  class  in  the  Schema  Library,  howevCT,  the  STEPattribute  class  maintaing  a 
pointer  to  the  value  for  an  attribute.  This  feature  is  used  to  access  an  attribute’s  values 
without  knowing  the  nature  of  the  attribute.  The  descriptive  information  about  the 
attribute  is  maintained  within  the  AttributeDescriptor  which  is  accessible 
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through  the  instance  ofthdSTEPattribute.  The  STEPattribute  class  maintains 
error  state  information  for  the  attribute.  The  error  state  is  accessed  by  the  STEPent  i  ty 
class  during  instance  validation. 

STEPattributeList 

The  STEPattributeList  class  is  the  key  to  providing  common  functionality  for 
subclasses  of  the  STEPent  ity  class.  The  list  can  be  used  to  traverse  the  attributes  of 
any  entity  instance.  Using  the  instances  of  the  STEPattribute  both  the  values  for 
and  the  descriptive  inf(Mination  about  the  attribute  can  be  accessed.  For  example,  the  list 
is  traversed  by  the  functimi  which  implements  the  exchange  file  format  for  reading  and 
writing  of  the  values  for  an  instance.  Similarly,  the  list  is  used  to  display  the  names  of  an 
entity’s  attributes  to  an  interactive  user. 

Registry 

The  purpose  of  the  Registry  is  to  provide  access  to  the  descriptive  information  about 
schemas,  types  and  attributes.  This  information  is  used  to  present  meaningful  informa¬ 
tion,  such  as  names,  to  users.  In  addition  the  Registry  has  a  mechanism  for  the 
creation  of  instances  based  on  the  entity  name.  The  traversal  of  the  schema  hierarchy  via 
pointers  to  the  parent  and  subtype  entities  is  also  facilitated  by  infcumation  in  the 
Registry. 

A  Registry  provides  two  important  functions: 

■  it  contains  symbolic  information  about  the  structures  (the  entities  and  their 
attributes)  described  in  the  implication  model. 

■  it  provides  a  mechanism  to  create  new  instances  of  an  entity  type  given  an  entity’s 
symbolic  name. 

The  Registry  used  in  the  VTS  software  contains  entries  associated  with  an  plica¬ 
tion  model  written  in  EXPRESS;  however,  the  Registry  class  may  alternatively  be 
populated  with  information  from  models  specified  in  a  different  data  mtviftiing 
language.  To  use  the  Registry  for  a  different  data  modeling  language,  appropriate 
descriptor  classes  (analogous  to  the  Entity  and  Attribute  Descriptors  described  below) 
must  be  defined  as  subtypes  of  the  Registry  Entry  class. 

Support  for  multiple  schemas  at  runtime  is  one  requirement  which  led  to  the  design  of 
file  Registry  class.  The  Registry  class  provides  a  mechanism  to  instanfij^te  a 
program  with  a  particular  plication  model.  In  the  design  of  the  initial  VTS  software 
only  one  pUcation  model,  and  therefore  one  instance  of  a  Registry,  will  be  used. 
However,  it  is  envisimied  that  multiple  registries  would  be  used  to  support  multiple 
schemas  in  a  single  program.  By  doing  so  the  user  would  be  able  to  switch  “contexts.” 

In  this  way  the  application  model  visible  to  the  user  could  be  switched  at  runtime. 

An  aspect  of  the  STEP  application  models,  currently  not  addressed  in  the  VTS  software 
design,  relates  to  the  wganization  of  the  plication  models.  The  VTS  software 
currently  is  not  addressing  these  requirements  because  the  organization  of  these  models 
and  the  relationship  of  this  organization  to  flie  EXPRESS  language  is  in  a  very  active 
stage  of  development.  It  is  anticipated  that  a  mechanism  for  supporting  multiple,  and 
possibly  overlping  or  nested,  plication  models  in  a  single  program  will  be  needed  to 
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support  the  emerging  organization.  As  these  requirements  are  defined  and  become  more 
stable,  more  support  for  these  will  need  to  be  incorporated  into  the  VTS  software 
design.  The  Registry  class  encapsulates  the  mechanism  to  support  future  application 
model  needs.  This  encapsulation  will  isolate  the  changes  to  the  VTS  software  needed  to 
support  the  new  organization. 

One  problem  area  is  entity  referencing  between  schemas.  Two  EXPRESS  language 
constructs  in  the  interface  specification  portion  of  EXPRESS,  USE  FROM  and 
REFERENCE  FROM,  allows  schemas  to  use  entities  from  other  schemas.  Hris  is  not 
handled  in  a  robust  way  by  the  current  version  of  fedex_plus  [McLay  90]  or  the  VTS 
libraries.  This  area  is  in  flux  in  the  EXPRESS  committee  and  other  committees  within 
the  STEP  community. 

As  an  aside,  the  class  descriptors  used  by  the  Registry  v/ere  developed  by  using  an 
early  version  of  the  Data  Probe  (see  the  section  Data  Probe:  An  Example  Application). 
A  model  of  EXPRESS  in  EXPRESS  was  created,  translated  to  C++  and  a  Data  Probe  of 
this  EXPRESS  of  EXPRESS  schema  was  created.  Data  entered  in  this  particular  Data 
Probe  was  used  to  prototype  the  class  information  which  we  desired  to  represent  in  the 
Registry.  This  iterative  design  process  has  proven  quite  useful  [Kramer92]. 

EntityDescriptor 

For  each  entity  in  the  aj^lication  model  an  entity  descriptor  is  created.  An  entity 
descriptor  encapsulates  the  minimum  set  of  symbolic  informaticMi  needed  by  the  VTS 
software  at  runtime.  The  entity  descriptor  is  represented  by  die  r.lass  Ent  i  tyDe  - 
scriptor.  This  class  is  used  to  populate  an  instance  of  the  Registry  class  and  is 
the  Reg i  stry  entry  for  an  EXPRESS  information  model.  Instances  of  this 
contain  the  foUowing  information: 

■  name 

■  schema 

■  subtype(s) 

■  supertype(s) 

■  attribute(s) 

■  creation  function 

One  entity  descriptor  is  created  for  each  entity  in  the  £q)plication  model.  The  entity 
descriptor  is  accessible  in  a  number  of  ways. 

■  The  entity  descriptor  is  represented  as  a  global  variable  in  the  Schema  library. 

■  Tbose  subclasses  of  the  STEPent  ity  class  which  are  instantiated  contain  apointer 
to  an  EntityDescriptor.  Each  instance  of  a  STEPent  ity  prants  to  the  entity 
descriptor  for  the  entity  type. 

■  When  an  entity  descriptor  is  stored  in  a  Registry,  it  is  accessible  from  the  Reg¬ 
istry  given  the  entity  name.  The  entity  name  serves  as  the  key  into  the  Regis¬ 
try. 
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AttrlbuteDescriptor 

A  description  of  each  attribute  is  also  contained  in  the  schema  dictionary  or 
Registry.  These  descriptions  are  most  easily  accessible  through  the  entity  descrip¬ 
tions  which  contain  direct  pointers  to  the  (tescriptions  of  the  attributes.  The  EXPRESS 
definition  of  the  attribute  descriptor  is  as  follows: 

ENTITY  attribute_descriptor; 
name:  STRING; 
type :  type_descriptor ; 
optionality:  BOOLEAN; 
uniqueness;  BOOLEAN; 
owner:  enti ty_descriptor; 

END_ENTITY; 

This  structure  describes  the  basic  properties  associated  with  an  attribute.  In  the  initial 
implementation  this  information  is  used  to  present  a  simple  description  of  the  attribute 
to  the  usct;  in  latCT  implementations  it  may  be  used  in  conjunction  with  constraint 
checking  on  values  of  attributes. 

The  initial  implementation  of  the  VTS  software  does  not  provide  support  for  derived 
attributes.  The  requirements  which  support  derived  attributes  have  not  been  identified 
for  this  design.  However,  it  is  anticipated  that  the  AttrlbuteDescriptor  concept 
will  be  extended  to  support  these  attributes. 

TypeDescriptor 


Much  of  the  informatioo  which  describes  an  attribute  is  contained  in  the  attribute’s 
To  support  this,  another  type  of  entity  is  introduced:  the  type_descriptor.  Due  to 
the  variety  of  tjqjes  available  in  an  EXPRESS  schema,  there  are  several  subt)pes  of 
type_descriptor.  The  foUovmg  EXPRESS  definitions  represent  file  basic 
type_descriptor: 

TYPE  base_type  = 

ENUMERATION  OF  ( 

INTEGER_TYPE,  STRING_TYPE,  REAL_TYPE,  ENTITY_TYPE, 
AGGREGATE_TYPE,  ENUM_TYPE,  REAL_PTR_TYPE,  INTEGER_PTR_TYPE , 
SELECT_TYPE,  BOOLEAN_TYPE,  LOGICAL_TYPE,  NUMBER_TYPE, BINARY_TYPE 
UNKNOWN_TYPE  )  ; 

END_TYPE; 

ENTITY  type_descriptor; 

name:  STRING  ; 

f undamental_type :  base_type ; 
description:  STRING; 

END_ENTITY; 

Hie  name,  fundamental_type  and  description  are  currently  implemented  in 
the  VTS  software.  The  subtypes  of  the  type_descriptor  are  not  implemented  in 
die  initial  implementation  of  the  VTS  software.  The  level  of  detail  provided  by  this 
design  is  not  a  priority  for  the  VTS  software.  The  information  encapsulated  in  the 
type_descriptor  represents  a  minimal  set  of  information  which  is  needed  at 
runtime. 
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The  type_descr  iptor  ena^sulates  the  area  which  will  be  expanded  for  future 
implementations  to  support  access  to  more  robust  type  information.  The  expanded  type 
information  is  particularly  necessary  for  the  software  to  evolve  to  support  tighter 
domain  restrictions  for  attribute  values  and  other  types  of  constraints. 

3.2  Data  Editor  Library 

One  of  the  goals  of  the  VTS  software  design  is  to  provide  a  clean  separation  of  the  soft¬ 
ware’s  functionality  and  the  interface.  Support  for  editing  is  contained  within  the  Data 
Editor  Library.  This  library  includes  functions  for  editing  individual  instances  and  for 
manipulating  groups  of  instances.  Group  manipulation  includes  merging  exchange  files, 
searching  sets  of  instances,  and  checking  sets  of  instances  for  completeness  with  respect 
to  the  ^plication  model.  The  Data  Editor  Library  also  maintains  the  state  of  an  interac¬ 
tive  editing  session. 

The  Data  Editor  Library  manages  information  from  two  areas.  First,  it  is  responsible  for 
managing  information  about  instances  of  STEPent  i  ty  with  regard  to  the  editing 
process.  This  information  is  used  as  the  subject  material  for  the  visual  objects  (views  of 
the  subject)  that  are  shown  to  the  user  with  the  VTS  user  interface.  (A  visual  object 
refers  to  an  object  in  the  VTS  Interface  Library  which  can  actually  be  seen  on  the 
computer  sween.)  The  information  in  the  visual  objects  can  then  be  viewed,  edited  and 
copied  back  to  the  underlying  subject  The  second  area  of  information  managed  by  the 
data  editor  is  information  about  the  display,  such  as: 

■  which  STEPentity  is  currently  being  displayed, 

■  which  of  the  STEPentity  instances  have  been  displayed, 

■  in  what  order  STEPentity  instances  are  displayed  in  the  list  of  STEPentity 
instances  read  from  an  exchange  file, 

■  in  what  order  available  entity  Q^pes  are  displayed, 

■  how  a  STEPentity  instance  has  been  saved, 

■  which  STEPent  i  ty  instances  are  marked  to  be  deleted, 

■  what  is  the  state  of  a  visual  display  of  a  STEPent  i  ty  instance  (is  writable  or  read¬ 
only) 

It  is  important  to  note  that  the  visual  objects  are  not  actually  created  or  placed  on  the 
screen  by  the  Data  Editor  Library.  The  Data  Editor  Library  maintains  infnnnatinn 
about  which  STEPentity  instances  have  an  associated  visual  object  and  the  state  associ¬ 
ated  with  those  objects.  The  Data  Editor  Library  is  only  loosely  tied  to  a  specific  user 
int^ace  library. 

3.2.1  Class  Relationships  within  Data  Editor  Library 

The  primary  classes  in  the  Data  Editor  Library  are  the  InstanceManager,  the 
ManagerNode,  and  the  STEPf  ile  class.  The  library  also  relies  on  the  Registry 
and  STEPentity  classes,  which  were  described  in  the  previous  section.  The  prime 
use  of  the  Instance  Manager  is  to  maintain  a  list  of  the  entire  set  of  instances  of 
STEPentity  for  a  particular  editing  session.  The  InstanceManager  is  also  used 
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by  the  STEPf  ile  class  to  maintain  information  about  the  header  section  associated 
with  a  particular  file. 


FIGURE  5  Data  EdKor  classes 


3.2.2  Relationships  to  other  Libraries 

Classes  in  the  Data  Editor  Ubrary  work  closely  with  the  classes  from  the  STEP  Class 
Library  and  VTS  Interface  Library  to  implement  a  grai*ical  editor  for  STEP  entities. 
The  VTS  Interface  Library  defines  visual  classes.  The  Data  Editor  Library  serves  as  a 
meditator  between  the  STEP  Class  Library  and  the  VTS  Interface  Library  (FIGURE  6). 
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FiGURE  6 


Data  Editor  Library  as  Mediator 


user  view  of  data  and 
interaction  control 


3.2.3  Classes 

The  classes  in  flie  Data  Editor  Library  primarily  perform  management  functions.  They 
implement  the  control  necessary  to  pass  control  messages  through  a  variety  of  data 
structures. 


TABLE  2 


Primary  Classes  of  the  Data  Editor  Library 


InstanceManager  ManagerNode 

STEPFile 

InstanceManager 

The  InstanceManger  maintains  a  set  of  instanrps 

The  primary  purpose  of  die  InstanceManager  class  is  to  keep  a  master  list  of 
instances  in  the  current  editing  session.  It  also  maintains  an  index  into  that  set  for  fast 
look  ups.  Whenever  a  new  instance  is  created  during  the  editing  session,  either  interac¬ 
tively  or  by  reading  in  a  data  file,  the  new  instance  is  added  to  the  master  Instance 
Manner. 

The  InstanceManager  class  also  maintains  other  instances.  For  example,  an 
Instance  Manager  instance  is  used  by  the  STEPf  ile  class  to  maintain  flie  header 
information  associated  with  a  particular  file.  Future  implementations  may  allow  the  user 
to  indicate  groupings  of  instances.  Such  a  feature  could  be  implftmented  using  the 
InstanceManager  class. 
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ManagerNode  ( MgrNode ) 

Hie  ManagerNode  class  maintains  an  association  between  an  object  of  the  STEPEn- 
t  i  ty  class  and  a  visual  object  in  the  user  interface.  The  Manage  rNode  class  allows 
the  application  model  to  ranain  independent  of  the  VTS  Interface  Library.  Tbe 
ManagerNode  maintains  an  editing  state  for  a  STEPent  i  ty  object  and  a  state  for 
the  display  object  The  editing  states  are 

■  saved  complete, 

■  saved  incomplete, 

■  marked  for  deletion,  and 

■  new 

The  saved  complete  state  indicates  that  the  instance  has  all  necessary  values  (i.e.  all 
non-optional  attributes  have  values)  and,  as  far  as  can  be  determined,  these  values  ate 
correct  TTie  saved  incomplete  indicates  that  the  instance  does  not  have  all  its  necessary 
values.  This  state  can  be  set  in  two  ways:  1)  An  etTw  resulted  when  the  validation  func¬ 
tion  from  the  STEPentity  class  was  executed.  2)  Or  the  user  interactively  set  the  state 
to  “incomplete”  through  the  user  interface.  The  new  state  indicates  that  the  instance  has 
been  recently  created  intoactively  and  has  not  been  edited. 

Hie  Manager  Node  maintains  information  about  which  instances  have  corresponding 
Display  objects  and  the  state  of  those  Display  objects.  Available  states  for  Display 
objects  are 

■  editable  display  object 

■  view-only  display  object 

■  unmafped  display  object 

■  no  display  olgect 

An  editable  display  object  is  visible  on  the  screen  and  may  be  edited  by  a  user.  A  view- 
only  display  object  is  visible  on  the  screen  but  may  only  be  viewed  by  the  user.  An 
unmapped  display  object  refers  to  a  display  object  which  has  been  created  but  is  not 
currently  visible  on  the  soeen.  (An  Unmapped  display  object  is  a  mechanism  for  buff¬ 
ering  the  implementation  of  the  display.) 

In  addition,  the  Manager  Node  also  maintains  intended  states  for  the  instances.  Intended 
states  are  used  to  mark  instances  for  attempted  state  changes  which  can  then  be  ^plied 
at  one  time.  For  example,  several  instances  can  be  marked  for  deletion  or  display,  and 
messages  to  initiate  the  ^ipropriate  operations  can  be  sent  to  the  respective  objects  at 
one  time.  Hiis  functionality  is  intended  to  aid  editing  across  the  Internet  or  modems 
where  display  performance  is  a  {xoblem. 

STEPFile 

The  STEPF  i  1  e  class  impl^ents  two  important  functions: 

■  controls  the  reading  and  writing  of  data  files,  and 

■  interfaces  with  the  file  system  for  opening  and  closing  files. 
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The  STEPf  ile  class  relies  on  the  STEPentity,  the  Registry,  and  the  Instance 
Manager  classes  for  implementing  the  functions  which  it  initiates. 

For  instance,  for  the  reading  and  writing  of  data  files  the  STEPf  i  le  class  serves  as  a 
driver.  The  STEPf  ile  class  opens  the  file,  controls  the  parsing  of  the  sections  of  the 
file,  initiates  the  creation  of  new  STEPentity  instances  (the  Registry  Hass  acdi- 
ally  creates  the  instances),  initiates  the  reading  or  writing  of  the  instances  (the 
STEPentity  class  actually  parses  the  instances),  updates  the  InstanceManager 
during  the  process,  and  finally  closes  the  file.  The  parsing  of  the  file  involves  two  passes 
over  the  Data  Section  (to  resolve  forward  references.)  These  passes  are  controlled  by  the 
STEPf  i  le  class.  Throughout  the  process  the  STEPf  i  le  class  monitors  the  error  state 
and  provides  appropriate  messages  as  errors  are  encounto-ed. 

The  STEPf  ile  class  also  implements  functions  to  save  the  working  state  of  an  editing 
session.  The  state  of  the  session  is  saved  into  a  file  similar  in  structure  to  an  exchange 
file:  a  working  session  file.  The  working  session  file  stores  the  state  of  the  instances  with 
the  editing  session  as  indicated  by  the  ManagerNode.  Unlike  the  exchange  file,  the 
wt^ng  session  file  does  not  require  STEPent  ity  instances  to  be  a  complete  rmd 
valid  state  (in  other  words,  attribute  values,  required  by  the  application  model,  can  be 
missing). 

CommandMeuiager 

The  CommandManager  isolates  and  encapsulates  editing  functionality.  Functionally 
the  command  manager  contains  commands  which  act  upon  the  selected  entities.  For 
example,  a  set  of  entities  which  are  to  be  saved  in  a  complete  state  are  maintained  by  the 
Command  Manager.  Other  operations  handled  by  the  CommandManager  include 
save  incomplete,  cancel,  and  delete.  These  commands  are  subsequently  processed  by 
the  Probe  class  (defined  in  the  VTS  Interface  Library,  see  FIGURE  7). 

DlsplayNode 


The  DisplayNode  is  the  class  which  contains  display  information  for  an  entity.  The 
DisplayNode  enc^sulates  all  display  information.  Furthermore  DisplayNodes 
only  exist  for  those  entities  which  are  actually  displayed  on  the  screen.  This  is  a  signifi¬ 
cant  performance  issue  as  we  expect  to  have  data  files  with  thousands  of  entities.  The 
display  node  points  to  the  actual  display  object  which  could  be  replaced  by  other  display 
objects  in  the  future  if  a  new  user  interface  is  chosen. 

3.3  VTS  Interface  Library 

The  VTS  Interface  Ubrary  was  designed  with  the  user  in  mind.  Users  are  expected  to  be 
people  famUiar  with  the  STEP  file  format  [ISO  21],  and  the  EXPRESS  language  [ISO 
1 1].  Users  interact  primarily  with  three  different  types  of  windows.  First  the  &itityType 
window  (see  FIGURE  1 0)  which  displays  a  list  of  all  entity  types  for  the  schema.  The 
other  window  is  the  Entity  Instance  window  (see  FIGURE  11)  which  displays  entity 

^  instances.  Display  of  these  instances  is  in  the  STEP  jhysical  file  formaL  a  format 

familiar  to  the  users.  The  third  window  type  is  the  STEP  Entity  Editor  (SEE)  window 
used  for  the  actual  editing  of  data. 
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Each  time  the  user  aeates  a  new  instance  or  views  an  existing  one  a  SEE  window  (see 
left  side  window  of  FIGURE  1 0)  is  created  and  displayed.  In  the  context  of  the  current 
implementation  which  uses  the  X  windows  system  each  SEE  is  created  as  a  separate 
window  which  can  be  moved  and  iconified.  This  approach  allows  the  user  to  interact 
with  the  windows  without  introducing  any  new  unknown  window  management 
commands. 

Where  possible  the  key  bindings  used  by  the  display  and  editable  objects  match  those 
found  in  GNU  emacs  [Schoo92].  This  library  works  with  a  window  manager  for  the  X 
window  system  environment.  Windows  inserted  onto  the  saeen  wiU  generally  be  deco¬ 
rated  and  placed  by  the  window  manager.  Moving  and  resizing  of  windows  will  be  done 
with  the  aid  of  the  window  manage. 

3.3.1  Class  Relationships  within  Library 


A  SEE  is  made  up  of  attribute  tows  and  buttons.  The  attribute  rows  pass  messages  to  the 
SEE,  as  ^propriate. 

The  information  communicated  between  the  different  windows  in  this  library  goes 
through  the  Probe  class.  For  example  when  the  save  button  on  a  SEE  is  hit,  the  infor¬ 
mation  goes  through  the  Probe  to  update  the  same  information  in  the  Instance  List 


FIGURE  7 
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3.3.2  Relationships  to  other  Libraries 


Much  of  the  lower  level  user  interface  functionality  is  derived  from  the  Interviews  class 
library,  a  public  domain  C++  library  available  from  Stanf<rd  (Linton9I].  TTie  Probe 
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class  manages  the  interaction  with  the  data  objects  managed  by  classes  of  other 
libraries.  The  Probe  class  manages  the  interaction  between  the  displays.  Its  main  func¬ 
tion  is  to  manage  the  display  information  and  to  keep  it  consistent  with  the  underlying 
information  objects.  (The  same  information  in  different  windows  is  kept  consistent) 

The  Probe  receives  an  interpretation  of  keystr(*e  or  button  commands  and  performs 
the  function.  For  example,  to  save  the  instances,  the  Probe  receives  the  list  of 
conunands  to  execute  from  the  CommandManager  (in  the  Data  Editor  Library). 

When  a  button  is  pushed  the  Probe  executes  a  single  ccanmand  for  the  selected 
instance  and  is  “notified”  by  the  generic  Interview  class  Subject  when  it  is  set  by  the 
button  object 

In  generaL  display  objects  such  as  those  in  the  SEE  point  to  the  actual  information 
objects  instantiated  fiom  other  classes  such  as  the  STEP  Class  Library.  The  SEE  itself 
points  to  an  instance  of  a  STEPent  i  ty  (from  the  STEP  Class  Library).  A  particular 
row  of  a  SEE  which  displays  the  attribute  information  for  a  particular  entity  points  to  a 
particular  attribute  and  an  instance  of  the  class  STEPattribute  (also  from  the  STEP 
Class  Library). 

3.3.3  Classes 

"Dte  classes  in  the  VTS  Interface  Library  group  the  functionality  of  existing  Interviews 
library  classes  into  a  meaningful  interface. 


TABLE  3 


Primary  Classes  of  the  VTS  User  Interface  Library 


StepEntityEditor  (SEE)  Probe 

Entity InstanceList  EntityTypeList 

StepEntityEditor  (SEE) 

The  StepEntityEditor  is  a  visual  representation  of  an  underlying  STEPentity. 
The  SEE  aUows  a  user  to  interactively  edit  a  STEPent  i  ty  on  the  screen.  The 
StepEntityEditor  class  is  independent  of  ttie  particular  STEPentity  type.  The 
SEE  sizes  itself  apiropriately  based  on  the  number  of  STEPattr  ibutes  contained  in 
the  underlying  STEPent  i  ty.  When  the  user  is  editing  through  a  SEE,  the  current  row 
corresponds  to  an  attribute  of  the  underlying  entity. 

SEE  windows  are  created  and  appear  when  a  command  for  creating  or  editing  an  entity 
instmce  is  given.  They  disappear  (unless  “pinned”)  when  a  cranmand  is  given  to  save 
the  instance,  delete  the  instance,  or  close  the  window.  A  single  SEE  window  is  shown  in 
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FIGURE  8 
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Tlie  SEE  window  for  an  instance  lists  the  name  of  the  type  of  entity  and  the  identifica¬ 
tion  number  of  the  entity  at  the  top  of  the  window.  Identification  numbers  are  assigned 
to  entity  instances  either  as  read  from  an  input  file  or  in  numerical  order.  The  remainder 
of  the  window  consists  mostly  of  rows  for  the  attributes  of  the  entity,  one  attribute  per 
row.  Each  row  has  three  sections:  flie  name  of  the  attribute,  a  space  for  the  user  to  enter 
the  value  of  the  attribute,  and  a  description  of  the  required  type  of  the  attribute.  When  an 
entity  instance  is  first  aeated,  the  middle  section  of  each  line  is  blank.  When  an  entity 
instance  is  edited,  blank  values  may  be  filled  in  or  existing  values  changed. 

The  message  line  in  a  SEE  is  a  place  where  the  software  can  give  the  user  feedback.  For 
example  if  the  user  attempts  to  save  an  entity  such  as  the  one  illustrated  above  without  a 
valid  x_coordinate  the  message:  missing  value  for  x_coordinate,  would 
appear  in  the  message  line. 

Each  SEE  window  has  a  “save”  buttrat  at  the  bottom.  When  this  button  is  selected,  the 
window  disappears,  and  the  contents  of  the  window  are  transcribed  to  the  Entity 
Instance  List. 

The  SEE  window  helps  prevent  errors  by  refusing  attempts  to  enter  invalid  data  for 
attribute  values  and  by  checking  data  types  again  when  an  instance  is  transcribed  from 
the  SEE  window  to  the  Entity  Instance  List  Invalid  data  is  not  transcribed. 

Operations  which  a  user  may  perform  via  a  SEE  can: 


■  activate  operatiras  using  an  emacs-like  key  binding  interface, 

■  create  new  instances  and  automatically  make  the  connection  to  the  “current” 
attribute, 

■  provide  both  key  bindings  and  visual  buttons  for  the  user. 


The  StepEntityEditor  provides  the  following  editing  operations  on  an  entity  instance: 

■  Save  Complete 

■  Save  Inccxnplete 


Application  Model  Specific  Layer 


■  Cancel 

■  Delete 

■  Replicate 

■  Edit  Attribute’s  Instance 

■  Marie  (select  maiked  instance  for  current  attribute) 

■  List  Values  (for  an  enumeration) 

EntitylnstanceLietDisplay 

The  EntityinstanceListDisplay  class  is  adisplay  object  It  contains  an  object 
which  is  a  list  of  string  representations  of  the  actual  underlying  data  entities.  This  sctoI- 
lable  list  is  the  primary  usct  interface  mechanism  for  selecting  particular  entities.  It  also 
contains  a  collection  of  buttons  which  the  user  can  use  to  perform  operations  on  the 
underiying  entities.  From  the  user  interface,  the  user  can  marie  an  entire  set  of  instances, 
delete  or  save,  and  invoke  these  operations  at  once  via  an  execute  button  (or  keystroke). 
Another  field  allows  the  user  to  search  for  particular  entities  by  entering  a  substring. 

EntltyTypeLlstDisplay 

The  EntityTypeDisplayList  has  many  of  the  same  functional  mechanisms  as 
the  Entity  InstanceDisplayList.  It  presents  the  user  with  a  list  of  types  which 
the  user  may  select.  Tbe  user  may  elect  to  create  a  new  instance  of  file  selected  type  or 
display  more  semantic  inftnmation  about  the  type.  This  window  alsp  contains  a 
searching  function. 

Probe 

The  Probe  is  the  main  grouping  object.  It  contains  pointers  to  file  InstanceMan- 
ager.  Registry,  STEPfile,  Command  Manager,  FileChooser, 
InstListDisplay ,  TypeListDisp.  It  also  has  a  number  of  menu  objects.  In  a 
sense  the  Probe  olyect  is  the  object  oriented  equivalent  of  amain  routine  in  aC 
program. 


4  Application  Model  Specific  Layer 


The  application  model  specific  layer  rqiresents  the  components  whidi  are  tailored  to  the 
^plication  model  undergoing  validation.  These  components  are  updated  eafh  time  the 
application  model  dianges. 

The  STEP  Schema  Class  Ubtaty  is  the  set  of  files  that  result  from  the  translation  of  an 
EXPRESS  schona.  These  files  are  generated  automatically  using  tbe  Fed-X  Toolkit 
[Clatk92]  for  translating  EXPRESS  and  are  produdble  firoin  an  EXPRESS  schema  The 
pro%rdmfedex_plus,  which  is  a  backend  to  Fed-X,  takes  a  conceptual  data  model  written 
in  EXPRESS  as  input  and  generates  three  C++  files  for  each  schema  [M(wris92].  The 
C++  code  in  these  files  provides  the  class  definitions  and  member  functions  for  STEP 
entities  needed  by  an  application  program 


25 


Validation  Testing  System:  Reusable  Software  Component  Design 


Applications  in  projects  working  on  process  planning  research  and  an  IGES  to  PDES 

translator  have  used  the  C++  code  produced  as  the  output  of fedex_plus.  The  STEP 

Schema  Class  Library  is  the  result  of  a  mailing  process  betweai  EXPRESS  and  C++. 

The  mappings  occur  as  foUows; 

■  EXPRESS  entities  are  translated  into  C++  classes  derived  from  the  rfass  STEPen  - 
tity. 

■  EXPRESS  attributes  are  translated  into  data  members. 

■  Public  access  functions  are  automatically  created  allowing  values  to  be  read  and 
written  to  the  data  members. 

■  Instances  of  Entity  and  Attribute  descriptors  are  created  for  populating  a  Regis¬ 
try. 


5  Data  Probe:  An  Example  Application 


The  Data  Probe  is  the  major  plication  whidi  uses  the  various  libraries  described  in 
this  document  It  is  intended  to  allow  people  involved  with  the  creation  and  testing  of 
STEP  Application  Protocols  to  examine  and  populate  data  files  corresponding  to  those 
models. 

New  versicHis  of  the  Data  Probe  may  be  automatically  generated  for  an  EXPRESS 
sdiema.  Each  Data  Probe  executable  is  specific  to  a  particular  schema.  A  UNIX  shell 
script  called  mkprobe  takes  as  input  an  EXPRESS  schma  and  outputs  a  new  Data 
Probe  specific  to  that  schema.  The  process  of  creating  a  new  Data  Probe  is  completely 
automated  through  this  process.  It  is  anticipated  that  users  will  not  be  working  with  very 
many  diffident  sdiemas  and  will  instead  concentrate  on  one  sdiema  at  a  time. 

FIGURE  1 0  shows  the  main  windows  of  the  Data  Probe  built  for  Part  42  of  STEP.  The 
editor  consists  of  four  types  of  persistent  windows,  all  of  which  may  be  manipulated  in 
the  typical  ways  (move,  open,  close,  hide,  expose,  resize,  etc.): 

1  Data  Probe  management  window  (FIGURE  9), 

2  STEP  Entity  Editor  (SEE)  windows  (ieft  side  of  FIGURE  1 0), 

3  an  Entity  Type  List  window  (right  side  of  FIGURE  1 0), 

4  and  an  Entity  Instance  List  window  (FIGURE  11). 

Any  number  of  temporary  STEP  Entity  Editing  (SEE)  windows  may  be  created  and 
destroyed  as  the  editor  is  being  used.  A  single  SEE  window  is  shown  in  the  left  side  of 
/FIGURE  1 0,  partly  obscuring  the  Entity  Type  List  window. 

Data  Probe  Management  Window 

The  Data  Probe  management  window  provides  the  user  with  systems  functions  such  as 
saving  or  appending  files,  clearing  the  Entity  histance  LisL  and  quitting  the  editor.  There 


is  al^  a  subwindow  for  brief  messages  to  flie  user.  In  FIGURE  9  the  status  window 
provides  feedback  that  an  instance  has  just  been  created. 


FIGURE  9  Data  Probe  Management  Window 
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Key  Bindings  &  Button  Codes  for  Step  Entity  Editor  Windows: 

I  Press  a  button  or  type  control-x  followed  by  the  appropriate  key  below  to  execute  a  command. 

closes  existing  window  opens  a  new  window  get  vaiue  from  list 

s  -  save  complete  r  -  replicate  instance  m  -  select  marked  instance  from  instance  list 

I  -  save  incomplete  e  -  edit  existing  instance/  I  -  pop  up  list  of  valid  attribute  values 

c  -  cancel  edits  create  and  edit  new  instance 

d  -  delete  STEP  entity 


Messages:  Create  Instance 


Clear 


Entity  Type  List  Window 

The  Entity  Type  List  window  contains  a  scroUable  Ust  of  aU  the  entities  defined  in  the 
EXPRESS  schema  used  to  create  the  editor.  Instances  of  these  entities  make  up  a  STEP 
file.  In  FIGURE  10,  the  first  few  entities  in  this  window  are  angle_measure,  area_mea- 
sure  and  axisl  j)lacement.  The  circle  entity  is  highlighted  in  this  window  because  the 
user  has  selected  it  Below  the  list  of  entities  there  are  some  command  buttons. 
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FIGURE  10 


Entity  Type  List  window  and  new  SEE 
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This  window  is  used  to  selea  the  type  of  entity  to  create  when  the  user  decides  to  create 
an  instance  of  an  entity.  The  user  simply  selects  the  name  of  the  oitity  type  to  be  created 
(by  pointing  at  the  name  with  the  mouse  cursor  and  clicking  a  mouse  button)  and  flien 
selects  the  “create”  command  button  in  a  similar  manner.  This  causes  a  sfp  window  to 
pop  up  for  a  new  instance  of  that  type  of  entity.  The  example  illustrates  an  instance  of 
“Circle”  has  just  been  created. 

Entity  Instance  List  Window 

Die  Entity  Instarree  List  window  has  two  main  parts.  Hie  top  part  has  the  ^ipearance  of 
the  “D^A”  section  of  a  STEP  file.  Entity  instances  ate  listed,  one  instance  per  line.  An 
indication  of  the  editing  states  (such  as  marked  for  deletion)  of  an  instance  may  be 
displayed  to  the  left  of  the  instance. 
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FIGURE  11 


Entity  Instance  List  window 
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Each  button  executes  its  action  immediately  on  the 
selected  instance.  The  ’Execute’  button  executes  all 
of  the  mari;s  ne?d  to  the  instances.  Use  the  key 
bindings  to  martcthe  Instances 
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The  bott(«i  pan  of  the  window  contains  the  controls  for  a  searching  utility  that  may  be 
used  to  find  text  strings.  The  bottcmi  part  also  contains  a  set  of  command  buttons  to 
perform  actions  on  instances  such  as;  delete,  modify,  view,  save,  etc.  To  use  flie 
command  buttons,  an  instance  is  selected  with  the  mouse,  and  then  the  desired 
command  button  is  selected  with  flie  mouse.  If  either  viewing  or  m(xlifying  is  selected, 
a  SEE  window  pops  up. 
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6  Conclusions,  Summary  and  Future  Directions 

A  functioning  system  called  the  Data  Probe  has  been  designed  and  implemented.  At  the 
time  of  writing  this  document  it  is  under  preliminary  testing  by  knowledgeable  users. 
The  implementation  of  a  set  of  class  libraries  has  proven  to  be  a  flexible  and  robust 
approach.  The  libraries  have  been  designed  to  allow  the  software  developer  the  fteedom 
to  choose  user  interface  styles  and  systems. 

The  initial  implementation  of  the  Data  Probe  is  limited  to  the  use  of  one  input  file  at  a 
time.  The  underlying  data  structures  howevw  will  allow  the  use  of  multiple  files  and  this 
extension  is  planned  for  the  future. 

Future  work  will  include  a  more  sophisticated  use  of  schemas  with  more  display  of 
schema  information  and  integration  of  a  document  browsing  utility  for  on-line  access  to 
the  ISO  documents.  Another  future  activity  is  the  move  to  an  SDAI  (STEP  Data  Access 
Interface).  SDAI  will  be  a  standard  mechanism  to  access  STEP  data.  As  the  standard  is 
defined  data  accessed  with  the  Data  Probe  will  move  through  an  SDAI  interface.  The 
intOTt  is  to  use  the  same  SDAI  interface  with  persistence  data  r^sitories  such  as  an 
object  oriented  data  base  for  the  persistent  storage  of  STEP 
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Appendix  A 

EXPRESS  Model  of  Registry  Classes 

The  following  EXPRESS  schema  is  a  model  of  EXPRESS.  This  model  was  developed 
as  a  basis  for  a  skeleton  of  schema  infonnation  from  an  EXPRESS  model  available  at 
nin-time  using  the  VTS  software.  (The  VTS  software  components  involved  are  the 
STEP  Class  Library  and  a  schema  library  generated  from  EXPRESS  using  fed-x-plus.) 

Mth  these  exceptions  this  schema  includes  everything  covered  by  EXPRESS-G: 

■  intra-schema  relationships 

■  cardinality 

■  derived  attributes 

SCHEMA  express_meta_inodel  ; 


TYPE  base_type  = 

ENUMERATION  OF  { 

INTEGER^TYPE,  STRING_TYPE,  REAL^TYPE,  ENTITY^TYPE, 
AGGREGATE_TYPE,  ENUM_TYPE,  REAL_PTR_TYPE , 
INTEGER_PTR_TYPE,  SELECT_TYPE,  BOOLEAN_TYPE, 
LOGICAL_TYPE,  NUMBER_TYPE,  BINARY_TYPE,  UNKNOWN_TYPE) ; 

(* 

attribute_type  = 

SELECT  { 

base_type,  type_descriptor  ) ; 

*) 

END_TYPE; 

ENTITY  type_descriptor 

{*  SUPERTYPE  OF  (  ONEOF  (  real_type__descriptor , 

string_type_descriptor,  array_type_descriptor , 
bag_type_de scriptor,  lis t_type_de scriptor, 
set_type_descriptor,  enuineration_type_des  crip  tor, 
select_type_descriptor  ) ) 

*) 


name: STRING  ; 

fundament a l_type : base_type ; 

{*  the  fundamental  type  will  default  to  certain  values 
according  to  the  subtype  of  the  type_de scriptor  *) 
referent_type: type_description; 
description : STRING ; 

END_ENTITY; 

ENTITY  real_type_descriptor 
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SUBTYPE  OF  ( type_descriptor) ; 
precision_spec:  OPTIONAL  INTEGER; 

END.ENTITY; 

ENTITY  string_type_descriptor 
SUBTYPE  OF  {type_descriptor) ; 
width:  OPTIONAL  INTEGER; 
f i xed_s i z  e :  BOOLEAN ; 

END_ENTITY; 

ENTITY  aggregate_type_descriptor 
ABSTRACT  SUPERTYPE 
SUBTYPE  OF  ( type_de script or ) ; 

(*  The  bounds  spec  have  been  simplified  to  integer  values  --  they 

can  actually  have  functional  values  *) 

bound_l ;  INTEGER ; 

bound_2 :  INTEGER; 

unique_elements:  BOOLEAN; 

399^^_domain_type :  type_descriptor ; 

END_ENTITY; 

ENTITY  array_type_descriptor 
SUBTYPE  OF  (aggregate_type_descriptor) ; 
optional_elements:  BOOLEAN; 

{*  WHERE  exists  (bound_l  &&  bound__2)  *) 

END_ENTITY; 


ENTITY  bag_type_descriptor 
SUBTYPE  OF  (aggregate_type_descriptor) ; 
{*  unique_elements:  always  TRUE  *) 
END^ENTITY; 

ENTITY  list_type_descriptor 
SUBTYPE  OF  (aggregate_type_descriptor) ; 
END^ENTITY; 

ENTITY  set_type.descriptor 
SUBTYPE  OF  (aggregate_type_descriptor)  ; 
(*  unique_elements:  always  TRUE  *) 
END_ENTITY; 
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ENTITY  entity_type_descriptor 
SUBTYPE  OF  ( type^descriptor) ; 
entity_type:  entity_descriptor; 

END_ENTITY; 

ENTITY  enumeration_type_descriptor 
SUBTYPE  OF  ( type_descriptor) ; 
elements:  LIST  OF  UNIQUE  STRING; 

END_ENTITY; 

ENTITY  select_type_descriptor 
SUBTYPE  OF  ( type_descriptor) ; 
elements:  LIST  OF  UNIQUE  type_descriptor; 

END_ENTITY; 

ENTITY  attribute_descriptor; 
narae:STRING; 

domain_type : type_descriptor ; 
optional_value : BOOLEAN; 
unique_value : BOOLEAN; 
owner  rent ity^descriptor ; 

END_ENTITY; 

ENTITY  inverse_attribute_descriptor 
SUBTYPE  OF  (attribute^descriptor) ; 
inverse^attribute  :  attribute_descriptor; 

(* 

role_attr:  ExplicitAttribute; 
i^in_cardinality :  bound_description; 
roax_cardinality :  bound_description; 
duplicates:  OPTIONAL  BOOLEAN; 

{*  3 -Apr- 19 92  kcm 

WHERE 

uniqueness_correct :  (EXISTS  (duplicates)  AND  max_cardinality  >  1) 
OR 

(max^cardinality  =  1  AND  NOT  EXISTS  (duplicates) ; 

*) 

*) 

END^ENTITY; 

ENTITY  schema_descriptor; 

name : STRING; 

END_ENTITY; 
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ENTITY  entity_descriptor; 
name : STRING ; 

originating_schema ;  schema_descriptor; 
abstract^entity :  BOOLEAN; 

subtypes;  OPTIONAL  LIST  OF  UNIQUE  entity_descriptor; 
super  types;  OPTIONAL  LIST  OF  UNIQUE  entity_descriptor; 
explicit_attr; OPTIONAL  LIST  OF  UNIQUE 
attribute_descriptor; 

derived^attr;  OPTIONAL  LIST  OF  UNIQUE  STRING;  --  not 
implemented  yet 

inverse_attr:  OPTIONAL  LIST  OF  UNIQUE 
inverse_attribute_descriptor; 

UNIQUE  name; 

{*  functions 

istypeof  {entity_de script or) : 
create_instance ; 

*) 

END_ENTITY; 

END_SCHEMA;  — express_meta_model 
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Appendix  B 

VTS  Document  Series 

This  document  complements  others  in  the  National  PDES  Testbed  Rqwrt  Series  which 
provide  detailed  technical  infonnation  relating  to  the  Testbed  software.  Those  docu¬ 
ments  which  specifically  address  aspects  of  the  Validation  Testing  System  are  desaibed 
below. 

Validation  Testing  Systems  Plan  lays  out  the  tasks  and  die  overall  approach  for  the 
initial  implementation  of  the  Validation  Testing  System.  (NISITR  4417) 

Proposed  Testing  Methodology  for  STEP  Appliccdion  Protocol  Validation  describes  the 
complete  process  used  to  develop  and  validate  ^plication  protocols.  This  methodology 
document  focuses  cm  the  analysis  of  application  models  and  planning  for  validation 
testing.  (NISTIR  4684) 

Validating  STEP  Application  Models  at  the  National  PDES  Testbed  describes  a  strategy 
for  automation  based  on  an  analysis  of  the  information  flow  in  the  application  protocol 
developnent  and  testing  process,  and  on  initial  experiences  with  automation  for  valida¬ 
tion  testing  at  flie  National  PDES  Testbed.  (NISITR  4735) 

Validation  Testing  System  Requirements  describes  functional  requirements  for  automa¬ 
tion  of  die  VTS.  This  document  also  provides  an  overview  of  the  VTS  software  environ- 
mait.  Requiranents  for  the  VTS  system  are  driven  by  the  STEP  development  effort  and 
reflect  the  needs  of  die  National  PDES  Testbed  users.  (NISTIR  4676) 

Architecture  for  the  Validation  Testing  System  Software  describes  an  architecture  for 
software  which  supports  the  testing  of  infcHmation  models  for  validity  and  correcmess. 
The  architecture  provides  a  basis  for  software  development  within  the  National  PDES 
Testbed.  (NISTIR  4742) 

Validation  Testing  System:  Reusable  Software  Component  Design  provides  guidelines 
for  the  implementation  of  the  VTS  software.  The  document  describes  the  design  of  soft¬ 
ware  libranes  which  fit  within  the  VTS  architecture.  These  libraries  enable  the  oeation 
and  support  of  tool  which  support  the  VTS  testing  methodology.  Designs  for  the  compo¬ 
nents  of  the  software  are  also  provided.  (NISTIR  4937) 
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